On-stack replacement, distilled

On-stack replacement (OSR) is essential technology for adaptive optimization, allowing changes to code actively executing in a managed runtime. The engineering aspects of OSR are well-known among VM architects, with several implementations available to date. However, OSR is yet to be explored as a general means to transfer execution between related program versions, which can pave the road to unprecedented applications that stretch beyond VMs. We aim at filling this gap with a constructive and provably correct OSR framework, allowing a class of general-purpose transformation functions to yield a special-purpose replacement. We describe and evaluate an implementation of our technique in LLVM. As a novel application of OSR, we present a feasibility study on debugging of optimized code, showing how our techniques can be used to fix variables holding incorrect values at breakpoints due to optimizations

Debugging Optimized Code Without Being Misled: Currency Determination

This paper describes a mapping between statements and breakpoint locations that ameliorates this problem. The mapping enables debugger behavior on optimized code that approximates debugger behavior on unoptimized code sufficiently closely for the user to use traditional debugging strategies. Optimization can also cause the value of a variable to be noncurrent --- to differ from the value that would be predicted by a close reading of the source code. This paper presents a method of determining when this has occurred, and shows how a debugger can describe the relevant effects of optimization. The determination method is more general than previously published methods; it handles global optimization and many flow graph transformations, and it is not tightly coupled to optimizations performed by a particular compiler. Necessary compiler support is also described. Categories and Subject Descriptors: D.2.5 [Software Engineering]: Testing and Debugging --- debugging aids; D.2.6 [Software Engineering]: Programming Environments; D.3.4 [Programming Languages]: Processors --- code generation, compilers, optimizatio

Debugging Optimized Code Without Being Misled

Optimizing compilers produce code that impedes source-level debugging. Examples are given in which optimization changes the behavior of a program even when the optimizer is correct, showing that in some circumstances it is not possible to completely debug an unoptimized version of a program. Source-level debuggers designed for unoptimized code may mislead the debugger user when invoked on optimized code. One situation that can mislead the user is a mismatch between where the user expects a breakpoint to be located and the breakpoint's actual location. A mismatch may occur due to statement reordering or discontiguous code generated from a statement. This work describes a mapping between statements and breakpoint locations that ameliorates this problem. The mapping enables debugger behavior on optimized code that approximates debugger behavior on unoptimized code closely enough that the user need not make severe changes in debugging strategies. Another situation that can mislead the us..

Producing an Accurate Call-Stack Trace in the Occasional Absence of Frame Pointers

This paper describes alternative ways to support this facility in the circumstance that this code is optimized away. Categories and Subject Descriptors: D.2.5 [Software Engineering]: Testing and Debugging --- debugging aids; D.2.6 [Software Engineering]: Programming Environments; D.3.4 [Programming Languages ]: Processors --- code generation, compilers, optimizatio

Computational grammars and Ambiguity: the bare bones of the situation

Linguists have been writing grammars for many years. Writing a computational grammar for use in an application is a different enterprise from writing a grammar to explore linguistic theory. Often, applications require a very small number of analyses of a sentence. Mechanisms must be found to reduce ambiguity. Here we present several techniques for reducing lexical and syntactic ambiguity and for ambiguity resulting from multi-word- expressions. 1 From Linguistics to Language Engineering Linguistics was first done on paper. In going from paper-and-pencil linguistics to computational linguistics to language engineering, new issues emerge. One thing in particular distinguishes computational grammars from "paper" grammars: a computational grammar must be completely and formally specified. It is not possible to simply assume the existence of a lexicon: the lexicon must be encoded. It is not possible to work only on a particular construction, unless one is willing to accept an inability to ..